\section{Implementation}
In this section we explain different aspects of the implementation of StarGazer, such as the ontology we developed and the tools we used.

\subsection{Ontology design}
The design of the StarGazer ontology has been driven by the hierarchy of celestial objects (see Figure \ref{classHierarchy}) which, in turn, is derived in large part from the Yerkes spectral classification for stars.  The remainder of the class hierarchy describes objects which are not stars, such as galaxies and nebulae, as well as stars or star-like objects, such as neutron stars and so-called proto-stars, which do not fit within the Yerkes system.  This ontology is implemented in software in that all resources in the StarGazer knowledge base are described in terms of it, and in that the class hierarchy corresponds to a hierarchy of Java interfaces which control the program's interaction with the triple store (see below).

\subsubsection{Expressivity and reasoning}
The application makes use of RDFS inference to the extent that the transitive nature of the relationship between child and parent classes is utilized in (and necessary for) the answering of queries.  No other aspect of RDFS reasoning is required of the current application.  Nonetheless, we have modeled the ontology in OWL for the reasons that:
\begin{itemize}
\item This allows us to use the convenient Protege-OWL ontology editor, without needing to export to RDFS. Protege has been useful not only for constructing the ontology, but also for populating it with representative instances: specific celestial objects drawn from sources on the Web, which we've used in our demo.
\item We use the owl:FunctionalProperty cardinality constraint as a form of documentation to indicate, for example, that a star may only have a single spectral type or mean solar radius.  While we do not perform OWL reasoning using this information, it is reflected in the Java implementation of the ontology, in which the ``get'' and ``set'' methods for a particular class and property are single-valued for functional properties, and set-valued for all others.
\end{itemize}

\begin{figure}[h]
\caption{StarGazer class hierarchy}
\label{classHierarchy}
\centering
\includegraphics[scale=0.75]{images/StarGazer_classHierarchy.png}
\end{figure}

\subsection{Project structure}
The most basic decision we faced in implementing StarGazer was the choice of a programming language. As a team, we unanimously agreed on Java due to the familiarity of each team member with that language, as well as the array of Java-based tools at our disposal.  Questions of expertise aside, an implementation in Python or Ruby might have been just as straightforward, as there are many serviceable Semantic Web, web services, and UI components available for these languages.  An implementation in C, using the Redland RDF tools, would even have been possible, if not as straightforward.  However, given our background, we found Java to be the best option for a collaborative implementation which we could finish quickly and competently.

\subsubsection{Development environment}
The StarGazer implementation is IDE-agnostic. For instance, while the project can be built in the Eclipse environment, it may also be (and has in fact been) built at the command line or within IntelliJ IDEA.  This was a firm requirement, as the various team members have diverse preferences with regard to development tools.  It was not a trivial requirement to fulfill, as some of the components we chose, such as Maven and GWT, are more or less convenient as plugins in one environment or another.

\subsubsection{Build system}
The choice of Apache Maven\footnote{http://maven.apache.org/} 2.0 as a build system was a controversial aspect of the implementation within our team. While we agree that it is a robust and appropriate tool for our project, the amount of effort required on the part of those team members not already familiar with the tool arguably exceeded the benefit of Maven over a less sophisticated build tool such as Ant, within the context of a small project such as StarGazer. On the other hand, the use of Maven in a longer-term continuation of the project would probably have considerable advantages over the use of Ant, as the straightforward nature of a Maven POM (project object model) and the ease of dependency management in Maven make the project far more maintainable and suitable for collaborative development.

\subsection{Front end}
Another less-than-obvious implementation choice was that of a UI toolkit. We decided early on that the user interface of StarGazer needed to be web-accessible and reasonably browser-independent, so as to maximize the potential user base of the tool and its deployment on various platforms (including mobile devices such as the iPhone). This ruled out otherwise attractive options such as the Swing\footnote{http://en.wikipedia.org/wiki/Swing\_(Java)} widget toolkit for Java, and the iPhone SDK.\footnote{http://developer.apple.com/iphone/} This left us with a number of Web-friendly options including the JavaScript-based Yahoo! User Interface Library (YUI),\footnote{http://developer.yahoo.com/yui/}, the Google Web Toolkit (GWT)\footnote{http://code.google.com/webtoolkit/} which cross-compiles Java to JavaScript, and Adobe Flash\footnote{http://en.wikipedia.org/wiki/Adobe\_Flash} (whose Player is widely deployed, despite the proprietary nature of the technology). In the end, we chose GWT on the basis of the expertise of one of our team members. GWT features a built-in client-server architecture, supports many basic HTML components, requires no knowledge of JavaScript, and has proven to be a good fit for our project, overall. We encountered some initial difficulties in integrating it with our Maven build system, which were solved through appropriate use of the GWT-Maven plugin.\footnote{http://code.google.com/p/gwt-maven/}.  

\begin{figure}[h]
\caption{StarGazer Front-End - User Querying Prompt}
\label{classHierarchy}
\centering
\includegraphics[scale=0.25]{images/Implementation1.png}
\end{figure}

\begin{figure}[h]
\caption{StarGazer Front-End - Returned Star Listing}
\label{classHierarchy}
\centering
\includegraphics[scale=0.25]{images/Implementation2.png}
\end{figure}

\begin{figure}[h]
\caption{StarGazer Front-End - Returned HTML for Star Listing}
\label{classHierarchy}
\centering
\includegraphics[scale=0.4]{images/Implementation3.png}
\end{figure}

\begin{figure}[h]
\caption{StarGazer Front-End - Returned RDF/XML for Star Listing}
\label{classHierarchy}
\centering
\includegraphics[scale=0.4]{images/Implementation4.png}
\end{figure}

\subsection{Triple store}
There are very many triple store solutions from which to choose, and a number of the top contenders are Java-based, including various Jena\footnote{http://jena.sourceforge.net/} and Sesame\footnote{http://www.openrdf.org/} stores. We chose Sesame, once again, primarily on the basis of the extensive experience of one of our team members. Additionally, Sesame has the advantage of a wide variety of loosely-coupled components, including but not limited to third-party software, which can simply be plugged into a Sesame stack to add a specific piece of functionality.  For instance, our application uses Aduna's ForwardChainingRDFSInferencer component, which can be layered on top of any Sesame Sail (Storage and Inference Layer) implementation to add eager RDFS reasoning capability. In the current revision of StarGazer, we layer the inferencer on top of Sesame's MemoryStore, a simple in-memory repository which is fast and appropriate for small, static data sets. MemoryStore is neither persistent nor scalable to very many triples, and neither does it behave very well when it is frequently updated (as the structure of its indices, and thus its performance tends to degrade in that case). As our knowledge base is quite small and is simply loaded from a file when the program is started up, there is currently no need for persistence or frequent updates. However, if in a continuation of the StarGazer project we introduce a larger and more dynamic knowledge base, we can easily swap out MemoryStore for a more appropriate component such as Sesame NativeStore, the AllegroGraph Java Edition,\footnote{http://www.franz.com/agraph/allegrograph/ag\_java\_edition.lhtml} or any other triple store with an associated Sail implementation.

\subsection{Java beans}
In object-oriented applications which deal with RDF data, there is always a question of how best to negotiate the divide between the OO domain of the programming language, and the multi-relational domain of RDF. One popular solution is so called ``deep integration'' of the programming language in question with RDF, by presenting RDFS classes as classes in the programming language, RDF properties as methods in the programming language, and instances of classes as objects which can be manipulated in familiar ways. These objects are created and destroyed at runtime, creating and removing type information from the triple store transparently to the application developer. Similarly, ``get'' and ``set'' methods may be used to retrieve structured information from and push structured information to the triple store.  Arguably the best Java-based deep integration toolkit is Aduna's Elmo\footnote{http://www.openrdf.org/} BeanPool toolkit, which interoperates with Sesame. In Elmo, RDFS classes correspond to Java interfaces which may either be defined manually (as we did for StarGazer) or generated automatically from an ontology. Instances of these interfaces, representing RDF resources may be created directly and pushed to the triple store, or retrieved using SPARQL-like queries.

\subsection{Search API}
The search API represents the boundary between the ``back end'' of the StarGazer implementation and those components layered on top of it. As there is currently no writing of data by a client to the triple store, the search API is a read-only interface to the knowledge base which makes use of the Java beans framework described above. Specifically, it allows the retrieval of Elmo-style Java beans from the entire knowledge base, subject to specific constraints. Currently, these constraints include the name of the object, its NGC (New General Catalog) number, its location in the sky as a two-dimensional region, and time of observation as an interval. As our knowledge base is quite small, we found it sufficient to retrieve all objects of the appropriate type, in response to a query, and then perform post-hoc filtering, ultimately returning references only to those objects which satisfy the constraints of the query. This is, however, not a scalable solution, and should be replaced with more sophisticated Elmo queries in any future releases. On the front end, a resource is rendered in HTML (we have no other format for search results at this time) by laying out all available information (statements about) the resource in a tabular format. This layout contains clickable hypertext links to an individual RDF/XML or HTML document for each rendered resource, as described in the following subsection.

\subsection{Resource API}
In keeping with the principles of Linked Data, all StarGazer resources (including individuals, classes and properties) are accessible via dereferenceable HTTP URIs. For example, a GET request for the URI denoting the ``Sun'' resource will yield either an associated RDF/XML description or an equivalent HTML respresentation, via the mechanism of content negotiation, depending on the headers provided with the request. This is achieved using a combination of OpenRDF components with the Restlet\footnote{http://restlet.org/} Lightweight REST Framework. The RDF/XML representation in question contains all statements in the StarGazer knowledge base in which the dereferenced resource URI appears as the subject. In other words, it contains all statements ``about'' the resource. The HTML representation contains this same information, but in a human-readable, tabular format. Missing from this Linked Data functionality is the mechanism of 303 redirection, in which a request for the URI of a non-information resource such as a star is answered with a 303 redirect to a representation -- either RDF/XML or HTML -- in which that resource is described. Currently, the application simply responds with the associated description rather than redirecting to it, an expedient violation of best practices which should be corrected in any future releases.

\subsection{Source code management}
In order to facilitate coordinated development among the team, we relied upon project hosting through Google Code. This conferred two key advantages. Firstly, it provided us access to a shared SVN repository which allowed us to manage revisions of all project code and documentation over the HTTPS protocol.  Secondly, Google Code allowed us to license and publish Stargazer for use by end users and other development teams.  For reference, Stargazer has been released under the MIT License.  Our Google Code project page can be found at http://stargazer.googlecode.com/.

